정보처리기사 공부 후 정리 자료입니다. 정확하지 않을 수 있으니 꼭 책을 참고해서 공부하세요

1. 요구사항 확인

소프트웨어 생명 주기

소프트웨어 생명 주기(Life Cycle)

• 소프트웨어 개발 방법론의 바탕이 되어 소프트웨어를 개발하기 위해 정의하고 운용 유지보수 등의 과정을 각 단계별로 나눈 것
• 스프트웨어 개발 단계와 각 단계별 주요 활동 및 활동의 결과를 산출물로 표현
• 표현 형태 : 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임

폭포수 모형

• 폭포수가 거슬러 올라갈 수 없듯이 이전 단계를 확실히 마무리하고 다음 단계로 진행하는 개발 방법론
• 소프트웨어 공학에서 가장 오래되고 폭넓게 사용된 생명 주기 모형
• 한 단계가 끝나고 결과물이 명확히 나와야 다음 단계로 넘어갈 수 있는 선형 순차적 모형

*

프로토타입 모형

• 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 시제품을 만들어 최종 결과물을 예측하는 모형
• 폭포수 모델의 단점을 보완하기 위해 만들어진 모형
• 사용자와 시스템 사이 인터페이스에 중점을 두어 개발

*

나선형 모형

• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발
• 누락되거나 추가된 요구사항을 첨가할 수 있음
• 정밀하고 유지보수 과정이 필요 없음

*

애자일 모형

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 진행하는 모형
• 고객과의 소통에 초점을 맞춘 모든 방법론을 통칭
• 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복
• 반복되는 주기마다 결과물에 해단 평가와 요구 수용
• 요구사항에 우선순위를 부여하여 개발 진행
• 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM

스크럼 기법

스크럼의 개요

• 팀이 중심이 되어 개발의 효율성을 높임
• 팀원 스스로가 팀을 구성하고 개발 작업에 대한 모든 것을 스스로 해결할 수 있어야 함

스크럼의 구성 요소

• 제품 책임자

  • 개발될 제품에 대한 이해도가 높고 요구사항을 책임지고 의사 결정할 사람
  • 개발 의뢰자나 사용자가 담당
  • 제품에 대한 요구사항, 백로그를 작성, 우선순위를 지정, 우선순위 갱신

• 스크럼 마스터

  • 팀이 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할
  • 일일 스크럼 회의를 주관하여 진행 사항을 점검하고 개발과정에서 발생된 장애 요소를 공론화하여 처리

• 개발팀

  • 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람
  • 최대 인원은 7~8명

스크럼 개발 프로세스

• 제품 백로그(Product Backlog)

  • 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록
  • 새롭게 도출되는 요구사항으로 인해 지속적 업데이트
  • 작성된 사용자 스토리를 기반으로 릴리즈 계획을 수립

• 스프린트 계획 회의(Sprint Planning Meeting)

  • 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
  • 처리할 요구사항을 개발자들이 나눠서 작업할 수 있도록 태스크라는 작업 단위로 나눠 개발자 별로 수행할 작업 목록인 스프린트 백로그(Sprint Backlog) 작성

• 스프린트(Sprint)

  • 실제 개발 작업을 진행하는 과정
  • 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간이나 양을 추정한 후 개발 담당자에게 할당
  • 태스크를 할당할 때는 개발자가 원하는 태스트를 직접 선별하여 담당할 수 있도록 하는 것이 좋음
  • 할당된 태스크는 할 일, 진행 중, 완료의 상태를 가짐

• 일일 스크럼 회의(Daliy Scrum Meeting)

  • 모든 팀원이 매일 약속된 시간에 짧은 시간동안 진행 상황을 점검
  • 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌
  • 남은 작업 시간은 소멸 차트에 표시

• 스프린트 검토 회의(Spring Review)

  • 부분 또는 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스트 수행

• 스프린트 회고(Sprint Retrospective)

  • 스프린트가 끝나고 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 점검하고 수행

XP(eXtreme Programming) 기법

XP의 개요

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 기법
• 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발하는 것이 목적
• 릴리즈의 기간을 짧게 반복하면서 요구사항 반영에 대한 가시성을 높임
• XP의 5가지 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

XP 개발 프로세스

• 사용자 스토리

  고객의 요구사항을 간단한 시나리오로 표현

• 릴리즈 계획 수립

  몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것에 대한 계획 수립

• 스파이크

  요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램

• 주기(이터레이션)

  하나의 릴리즈를 더 세분화하여 한 단위

• 승인 검사

  하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트

  사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행

• 소규모 릴리즈

  고객의 반응을 기능별로 확인하고 고객의 요구사항에 유연하게 대응

  진행된 이터레이션이 모두 완료되면 고객에 의한 최종 테스트 수행 후 최종 결과물을 고객에게 전달

XP의 주요 실천 방법

• Pair Programming : 다른 사람과 함께 프로그래밍 수행
• Test-Driven Development : 실제 코드 작성 전 테스트 케이스를 먼저 작성하여 무엇을 해야할지 파악
• Whole Team : 개발에 참여하는 모든 구성원은 각기 역할이 있어 책임을 다해야 함

개발 기술 환경 파악

개발 기술 환경의 정의

• 개발하고자 하는 소프트웨어와 관련된 O/S, DBMS, Middle Ware 등을 선정할 때 고려해야 할 사항을 기술하고 오픈 소스 사용 시 주의해야 할 내용을 제시

운영체제(Operating System)

• 컴퓨터 시스템 자원을 효율적으로 관리하여 사용자가 컴퓨터를 편리하고 사용할 수 있도록 환경을 제공하는 소프트웨어
• 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 주변 기기, 구축 비용
• 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 관리해주는 소프트웨어
• 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

웹 애플리케이션 서버(WAS)

• 사용자의 요구에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어
• 요구사항 식별 시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

오픈 소스(Open Source)

• 누구나 제한없이 사용할 수 없도록 소스 코드를 공개한 것
• 라이선스를 만족하는 소프트웨어
• 요구사항 식별 시 고려사항 : 라이선스의 종류, 사용자의 수, 기술의 지속 가능성

요구사항 정의

요구사항의 개념과 특징

• 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등
• 요구사항이 제대로 정의되어야 이를 토대로 이후 과정의 목표와 계획의 수립이 가능

요구사항의 유형

• 기술하는 내용에 따른 분류

  • 기능 요구사항 : 시스템이 무엇을 하고 어떤 기능을 하는지에 대한 사항
  • 비기능 요구사항 : 품질이나 제약사항에 대한 사항

• 기술 관점과 대상의 범위에 따른 분류

  • 사용자 요구사항 : 사용자의 관점에서 본 시스템이 제공해야 할 사항
• 시스템 요구사항 : 개발자의 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 사항

요구사항 개발 프로세스

*

• 요구사항 도출

  • 요구사항이 어디에 있고 어떻게 수집할지 식별하고 이해하는 과정
  • 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스 케이스 등
  • 브레인스토밍 : 3인 이상이 자유롭게 아이디어를 산출해 내는 방법
  • 유스케이스 : 사용자의 요구사항을 기능 단위로 표현

• 요구사항 분석

  • 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 걸러내는 과정

• 요구사항 명세

  • 요구사항을 분석한 후 승인될 수 있도록 문서화하는 과정
  • 소프트웨어 요구사항 명세서 : 소프트웨어가 반드시 제공해야 하는 기능, 특징, 제약조건을 명시

• 요구사항 확인

  • 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하게 작성되었는지 검토하는 과정

요구사항 분석 기법

요구사항 분류

• 요구사항을 명확히 확인할 수 있도록 정해진 기준으로 분류

  • 기능/비기능 요구사항 분류

• 제품/과정으로 분류

  • 우선순위로 분류

개념 모델링

• 요구사항의 현실 세계의 상황을 단순화하여 개념적으로 표현하는 과정
• 실세계 문제에 대한 모델링은 요구사항 분석의 핵심
• 개체와 개체 간의 관계 및 종속성을 반영
• 개념 모델은 다양하게 표현
• 주로 UML을 사용

요구사항 할당

• 요구사항을 만족시키기 위한 구성 요소를 식별

요구사항 협상

• 요구사항이 서로 충돌될 경우 해결하는 과정
• 적절한 기준점을 찾아 합의하는게 좋음
• 서로 충돌하는 경우 우선순위를 부여하면 해결에 도움이 됨

정형 분석

• 구문과 의미를 같은 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현하고 분석하는 과정

요구사항 확인 기법

요구사항 검토

• 문서화된 요구사항을 훑어보면서 확인하는 과정
• 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서 등을 완성한 시점에 이루어짐

프로토타이핑

• 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정

• 장점

  • 빠르고 반복되는 제작을 할 수 있어 발전된 결과물을 얻을 수 있음
  • 최종 시스템을 완성하기 전에 추가 또는 변경된 요구사항에 대한 피드백 가능

• 단점

  • 사용자의 관심이 핵심에서 벗어나 프로토타입 제작에만 집중될 수 있음
• 지속적이고 반복적인 개선에 대한 비용이 부담될 수 있음

모델 검증

• 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족하는지 검증하는 과정

인수 테스트

• 사용자가 실제로 사용될 환경에서 요구사항이 모두 충족되는지 사용자 입장에서 확인하는 과정

UML(Unified Modeling Language)

UML의 개요

• 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어
• 객체지향 방법론의 장점을 통합하였으며 OMG(Object Management Group)에서 표준으로 지정

사물

• 모델을 구성하는 가장 중요한 기본 요소
• 다이어그램 안에서 관계가 형성될 수 있는 대상

• 구조 사물

  • 시스템의 개념적, 물리적 요소 표현
  • 클래스, 유스케이스, 컴포넌트, 노드 등

• 행동 사물

  • 시간과 공간에 따른 요소들의 행위 표현
  • 상호작용, 상태 머신 등

• 그룹 사물

  • 요소들의 그룹으로 묶어서 표현
  • 패키지

• 주해 사물

  • 부가적인 설명이나 제약조건 등 표현
  • 노트

관계

• 사물과 사물 사이의 연관성 표현

• 연관 관계

  • 2개 이상의 사물이 서로 관련되어 있음을 표현
  • 실선과 화살표로 연결하여 표현하지만 양방향 관계의 경우 화살표 없이 실선으로 연결하여 표현

*

사람과 집이 1:1 관계

교수는 1명 이상의 학생을 가르치고 학생은 1명 이상의 교수에게 가르침을 받음

• 집합 관계

  • 하나의 사물이 다른 사물에 포함되어 있는 관계
  • 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 빈 마름모를 연결하여 표현

프린터는 컴퓨터에 연결해서 사용할 수 있음

• 포함 관계

  • 집합 관계의 특수한 형태로 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
• 부분(포함되는 쪽)에서 전체(포함하는 쪽)로 속이 채워진 마름모를 연결하여 표현

문을 열 수 있는 키는 하나이고 해당 키로 다른 문은 열 수 없음

• 의존 관계

  • 사물 사이에 연관은 있으나 필요에 의해서 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
  • 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표 연결

출석률은 학점을 낼 때 영향을 미침

• 일반화 관계

  • 하나의 사물이 다른 사물에 비해 일반적인지 구체적인지 표현
  • 구체적인 사물에서 일반적인 사물 쪽으로 속이 빈 화살표를 연결

*

• 실체화 관계

  • 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화할 수 있는 관계
  • 사물에서 기능 쪽으로 속이 빈 점선 화살표 연결

*

다이어그램

• 사물과 관계를 도형으로 표현
• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램 사용

• 구조적 다이어그램

  • 클래스 다이어그램 : 클래스, 클래스가 가지는 속성, 클래스 사이 관계 표현
  • 객체 다이어그램 : 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 컴포넌트 다이어그램 : 구현 단계에서 사용되며 컴포넌트 간의 관계나 인터페이스를 표현
  • 패치 다이어그램 : 구현단계에서 사용되며 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현
  • 복합체 구조 다이어그램 : 복잡한 구조를 가지는 클래스 혹은 컴포넌트의 내부 구조 표현

• 행위 다이어그램

  • 유스케이스 다이어그램: 사용자의 요구를 분석하여 기능 모델링 작업에 사용됨
  • 시퀀스 다이어그램: 상호 작용하는 시스템이나 객체들이 주고받는 메시지 표현
  • 커뮤니케이션 다이어그램 : 객체들이 주고받는 메시지를 표현할 뿐 아니라 객체들 간의 연관까지 표현
  • 상태 다이어그램: 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 어떻게 변화하는지 표현
  • 활동 다이어그램: 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
  • 상호작용 개요 다이어그램 : 상호작용 다이어그램 간의 제어 흐름 표현
  • 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현
• 패키지 다이어그램 : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현

2. 화면 설계

사용자 인터페이스(User Interface)

사용자 인터페이스의 개요

• 사용자와 시스템 간의 상호작용을 원활하게 도와주는 장치나 소프트웨어

• 사용자 인터페에스의 3가지 분야

  • 정보 제공과 전달을 위한 물리적 제어에 관한 분야
  • 콘텐츠의 상세적인 표현과 전체적인 구성에 관한 분야
  • 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야

사용자 인터페이스의 구분

• CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이루어지는 인터페이스
• GUI(Graphic User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 인터페이스
• NUI(Natural User Interface) : 말이나 행동으로 조작하는 인터페이스

사용자 인터페이스의 기본 원칙

• 직관성, 유효성, 학습성, 유연성

사용자 인터페이스의 설계 지침

• 사용자 중심, 일관성, 단순성, 결과 예측 가능, 가시성, 표준화, 접근성, 명확성, 오류 발생 해결

UI 표준 및 지침

UI 표준 및 지침의 개요

• UI 표준과 지침을 토대로 기술의 중립성(표준), 보편적 표현 보장성(접근성), 기능의 호환성이 고려되었는지 확인

한국형 웹 콘텐츠 접근성 지침(KWCAG)

• 장애인과 비장애인이 동등하게 접근할 수 있는 웹 콘텐츠 제작의 방법 제시
• 웹 콘텐츠 접근성 지침 준수를 위한 고려사항

*

• 네비게이션 : 사용자가 사이트에서 원하는 정보를 빠르게 찾도록 도와주는 장치

전자정보 웹 표준 준수 지침

• 정부기관의 홈페이지 구축시 반영해야 할 최소한의 규약

• 전자정부 웹 표준 준수 지침 사항

  • 내용의 문법 준수
  • 내용과 표현의 분리
  • 동작의 기술 중립성 보장
  • 플러그인의 호환성
  • 콘텐츠의 보편적 표현
  • 운영체제에 독립적인 콘텐츠 제공
  • 부가 기능의 호환성 확보
  • 다양한 프로그램 제공

UI 설계 도구

사용자의 요구사항에 맞게 UI를 설계할 때 사용하는 도구

와이어프레임

• 기획 초기 단계에서 제작하는 것으로 페이지에 대한 대략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계
• 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

목업

• 와이어프레임보다 좀 더 실제 화면과 유사하게 만드는 정적인 형태의 모형
• 파워 목업, 발사믹 목업 등

스토리보드

• 와이어프레임에 콘텐츠에 대한 설명이나 페이지 간 이동 흐름 등을 추가한 문서
• 디자이너와 개발자가 최종적으로 참고하는 작업 지침서
• 서비스 구축을 위한 모든 정보가 담겨 있어야 함
• 파워포인트, 키노트, 스케치, Axure 등

프로토타입

• 와이어프레임이나 스토리보드 등에 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
• 작성 방법에 따라 페이퍼/디지털 프로토타입으로 나눔
• HTML/CSS, Axure, Flinto, 네이버 포로토나우, 카카오 오븐 등

유스케이스

• 사용자 측면에서의 요구사항으로 사용자가 원하는 목표를 달성하기 위해 수행할 내용 기술

UI 요구사항 확인

새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계

*

목표 정의

• 사용자들을 대상으로 인터뷰를 하고 사용자들의 의견이 수렴된 비즈니스 요구사항을 정의

• 인터뷰 진행 시 유의 사항

  • 사업적, 기술적 요구사항을 명확히 이해

• 가능한 개별적인 진행

  • 한 시간을 넘기지 않는게 좋음
• 사용자 리서치 시작 전 해야 함

활동 사항 정의

• 조사한 요구사항을 토대로 앞으로 해야 할 활동 사항을 정의
• 기술의 발전 가능성을 파악하고 UI 디자인의 방향 제시

UI 요구사항 작성

• 여러 경로로 수집된 사용자의 요구사항을 검토하고 분석하여 UI 개발 목적에 맞게 작성해야 함
• 실 사용자 중심, 여러 사람 인터뷰

요구사항 요소 확인

• 파악된 요구사항 요소의 종류와 각각의 표현 방식 등을 검토
• 데이터 요구, 기능 요구, 제품/서비스의 품질, 제약 사항

정황 시나리오 작성

• 사용자의 요구사항을 도출하기 위해 작성
• 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사
• 개발하는 서비스의 모습을 상상하는 첫번째 단계로 사용자 관점에서 시나리오를 작성해야 함

요구사항 작성

• 정황 시나리오를 토대로 작성

품질 요구사항

품질 요구사항

• 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는 가를 나타내는 것
• ISO/IEC 9126 : 국제 표준으로 소프트웨어 품질 특성과 평가를 위한 표준 지침

*

*

UI 프로토타입 제작 및 검토

UI 프로토타입의 개요

• 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형
• 테스트 가능, 최대한 간단하게 만들어야 함, 최종 제품의 작동 방식 반드시 포함, 실사용자 대상 테스트

UI 프로토타입의 장단점

• 장점

  • 사용자를 설득, 이해시키기 쉬움
  • 요구사항을 점검하며 혼선은 예방하므로써 개발 시간을 줄일 수 있음
  • 사전 오류 검출 가능

• 단점

  • 프로토타입 제작으로 인해 작업 시간을 증가시킬 수 있음

• 필요 이상의 자원 소모 가능

  • 부분적으로 작업 시 중요한 작업이 생략될 수 있음

프로토타이핑의 종류

• 페이퍼 프로토타입

  • 아날로그 방법(스케치, 글, 그림) 등을 이용하여 직접 작성
  • 제작 기간이 짧고, 제작 비용이 적을 경우, 업무 회의가 빠를 경우, 급하게 만들어야 하는 경우 사용

• 디지털 프로토타입

  • 프로그램을 사용하여 작성
  • 재사용이 필요하거나, 완성 제품과 비슷하게 만들어야 하거나, 숙련된 전문가가 있을 때 사용

UI 프로토타입 계획 및 작성 시 고려사항

• 계획 시 고려사항

  • 일정은 아키텍처가 확정 ~ 프로젝트 실제 분석 작업 완료 사이에 진행해야 함
  • 프로토타입을 통해서 발생하는 이슈를 모두 취합하여 해결 방법을 제시
  • 진행하면서 가장 많은 시간이 소요된 구간을 찾아 그 원인을 분석하여 해결 방법을 제시

• 작성 시 고려사항

  • 프로젝트의 상황을 감안해서 프로토타입의 범위를 정해야 함
  • 완성된 프로토타입이 실제 개발에 참조될 수 있는 지 확인

UI 프로토타입 제작 단계

*

UI 설계서 작성

UI 설계서의 개요

• 사용자의 요구사항을 바탕으로 UI 설계를 구체화하여 작성하는 문서

UI 설계서 작성 순서

*

UI 상세 설계

UI 시나리오 문서의 개요

• UI 설계서를 바탕으로 실제 설계 및 구현을 위해 모든 화면에 대한 자세한 설계를 진행
• 시나리오를 작성해야 함
• 사용자 인터페이스의 기능 구조, 대표 화면, 화면 간 상호작용의 흐름, 다양한 상황에서의 예외 처리 등을 문서로 정리

UI 시나리오 문서 작성 원칙

• 개발자가 전체 UI 기능과 작동 방식을 이해할 수 있도록 구체적으로 작성
• UI 요소와 인터랙션을 일반 규칙으로 정의
• 인터랙션의 흐름을 정의하고 인터랙션의 순서, 분기, 조건, 반복 등을 명시
• 예외 상황에 대비한 다양한 케이스를 정의

UI 시나리오 문서 작성을 위한 일반 규칙

• 주요 키의 위치와 기능

  • 모든 화면에 공통적으로 배치되는 주요 키의 위치와 기능을 설명
  • 여러 화면 간 일관성 보장

• 공통 UI 요소

  • UI 요소를 언제 어떤 형태로 사용할 지 정의
  • 사용자의 조작에 대한 반응하는지에 대한 흐름을 설명

• 기본 스크린 레이아웃

  • 모든 화면에 공통적으로 나타나는 요소들에 대한 위치와 속성을 정의

• 기본 인터랙션 규칙

  • 터치 제스처 등에 공통적으로 사용되는 조작 방법과 화면 전환 효과 등을 기술

• 공통 단위 태스크 흐름

  • 많은 기능들에 공통적으로 사용되는 삭제, 검색, 매너 모드 상태 등에 대한 인터랙션 흐름 설명

• 케이스 문서

  • 다양한 상황에서 공통적으로 적용되는 시스템의 동작을 정의한 문서

UI 시나리오 문서의 요건

• 완전성 : 누락되지 않도록 상세히 기술
• 일관성 : 서비스의 목표, 요구사항, UI 스타일이 모두 일관성을 유지해야 함
• 이해성 : 누구나 쉽게 이해할 수 있도록 설명
• 가독성 : 표준화된 템플릿을 활용하여 읽기 쉽도록 해야 함
• 수정 용이성 : 시나리오의 수정, 개선이 쉬워야 함
• 추적 용이성 : 변경 사항이 언제 어떻게 왜 발생했는지 쉽게 추적할 수 있어야 함

HCI / UX / 감성공학

HCI(Human Computer Interaction or Interface)

• 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 개발, 연구하는 학문
• 최종 목표는 시스템을 사용하는데 있어 최적의 사용자 경험을 만드는 것

UX(User Experience)

• 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총제적인 경험

감성 공학

• 제품이나 작업환경을 사용자의 감성에 맞도록 설계 제작하는 기술

3. 애플리케이션 설계

소프트웨어 아키텍처

소프트웨어 아키텍처의 설계

• 소프트웨어의 골격이 되는 기본 구조
• 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체
• 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고,
• 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정

모듈화

• 소프트웨어의 성능을 향상하거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 시스템의 기능들을 모듈 단위로 나누는 것
• 모듈의 크기와 개수는 반비례관계 개수와 통합 비용은 비례 관계

추상화

• 문제의 전체를 설계 후 세분화하여 구체화하는 과정
• 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어 여러 가지 요인들을 테스트할 수 있음
• 최소 비용으로 실제 상황에 대처할 수 있고 시스템의 구조 및 구성을 대략적으로 파악할 수 있음

• 추상화 유형

  • 과정 추상화 : 전반적인 흐름만 파악
  • 데이터 추상화 : 데이테의 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체
  • 제어 추상화: 이벤트의 발생의 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체

단계적 분해

• 문제를 상위 중요 개념으로부터 하위의 개념으로 구체화하는 분할 기법
• 추상화의 반복으로 세분화

정보 은닉

• 한 모듈 내부에 포함된 정보들을 감추어 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 다른 모듈과 커뮤니케이션을 할 때는 필요한 정보만 인터페이스를 통해 주고받음
• 모듈을 독립적으로 수행하기 때문에 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수가 용이

소프트웨어 아키텍처의 품질 속성

• 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지하고 보장할 수 있게 설계되었는지를 확인하기 위해 품질 요소들을 구체화시켜 놓은 것

*

소프트웨어 아키텍처의 설계 과정

*

아키텍처 패턴

아키텍처 패턴의 개요

• 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• 시스템의 구조를 구성하기 위한 기본적인 틀을 제공
• 서브시스템과 그 역할이 정의되어 있어 서브시스템 사이 관계와 규칙, 지침 등이 포함되어 있음

• 아키텍처 패턴의 장점

  • 개발 시간을 단축시킴
  • 고품질의 소프트웨어 생산
  • 검증된 구조로 작업
  • 시스템 구조를 이해하기 쉬워 개발에 참여하지 않아도 유지보수가 쉬움

레이어 패턴

• 시스템을 계층으로 구분하여 구성
• 각각의 서브 시스템이 계층 구조를 이룸
• 상위 계층은 하위 계층에 대한 서비스 제공자가 되고 하위 계층은 상위 계층의 클라이언트가 됨
• 마주 보는 두 계층 사이에만 상호 작용이 이루어짐
• 특정 계층만을 교체해 시스템을 개선하는 것이 가능

클라이언트-서버 패턴

• 하나의 서버와 다수의 클라이언트로 구성
• 사용자는 클라이언트를 통해 서버에 요청하고 응답을 받아 사용자에게 제공
• 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지
• 요청을 위하여 동기화되는 경우를 제외하고는 서로 독립적임

파이프-필터 패턴

• 데이터 스트림(데이터가 송수신되거나 처리되는 흐름) 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송
• 필터 컴포넌트는 재사용성이 좋고 추가가 쉬워 확장이 용이
• 필터 컴포넌트를 재배치하여 다양한 파이프라인 구축 가능
• 데이터 변환, 버퍼링, 동기화 등에 사용

모델-뷰-컨트롤러 패턴(MVC)

• 서브시스템을 3개의 부분으로 구조화
• 모델 : 서브시스템의 핵심 기능과 데이터 보관
• 뷰 : 사용자에게 정보 표시
• 컨트롤러 : 사용자로부터 받은 입력 처리
• 각 부분은 별도로 분리되어 있어 서로 영향을 받지 않고 독립적인 개발 작업 수행
• 여러 개의 뷰를 만들 수 있어 한 개의 모델에 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합

기타 패턴

• 마스터-슬레이브 패턴 : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식
• 보로커 패턴 : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트를 연결
• 피어-투-피어 패턴 : 피어를 하나의 컴포넌트로 간주하여 각 피어는 클라이언트 또는 서버가 될 수도 있음
• 이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
• 블랙보드 패턴 : 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능하여 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음
• 인터프리터 패턴 : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고 기호마다 클래스를 갖도록 구성

객체지향(Object-Oriented)

객체지향의 개요

• 현실 세계의 개체를 기계의 부품처럼 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 객체를 조립하여 작성할 수 있는 기법
• 구조적 기법의 문제점을 해결하기 위해 사용
• 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있어 유지보수가 쉬움
• 복잡한 구조를 단계적이고 계층적이게 표현
• 멀티미디어 데이터 및 병렬 처리 지원
• 객체, 클래스, 캡슐화, 상속, 다형성

객체

• 데이터와 데이터를 처리하는 함수를 묶어 캡슐화한 하나의 소프트웨어 모듈
• 데이터 : 객체가 가지고 있는 정보
• 함수 : 객체가 수행하는 기능으로 데이터를 처리하는 알고리즘

• 객체의 특성

  • 객체는 독립적으로 식별 가능한 이름을 가지고 있음
  • 객체의 상태는 시간에 따라 변함
  • 객체 간의 상호 연관성에 의해 관계 형성
  • 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며 객체는 행위의 특징을 나타낼 수 있음
  • 객체는 일정한 기억 장소를 가지고 있음

클래스

• 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 인스턴스 : 클래스에 속한 각각의 객체
• 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것
• 슈퍼 클래스 : 특정 클래스의 부모(상위) 클래스
• 서브 클래스 : 특정 클래스의 자식(하위) 클래스

캡슐화

• 데이터와 함수를 하나로 묶은 것
• 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적이기 때문에 외부에서 변경하기 어려움

상속

• 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
• 하위 클래스는 부모 클래스의 모든 속성과 연산을 다시 정의하지 않고 사용할 수 있음
• 하위 클래스는 상속받은 속성 외에 새로운 속성과 연산을 첨가하여 사용할 수 있음
• 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것

다형성

• 메시지에 의해 객체가 연산 수행하게 될 때 하나의 메시지에 대해 각각의 클래스가 가지고 있는 고유한 특성으로 응답할 수 있는 능력
• 객체지향의 오버로딩의 개념

모듈

모듈의 개요

• 모듈화를 통해 분리된 시스템의 각 기능들
• 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용
• 단독으로 컴파일 가능하며 재사용 할 수 있음
• 각 모듈의 기능이 서로 독립적이고 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함
• 독립성이 높을수록 모듈을 수정해도 다른 모듈에 영향이 없어 오류가 발생해도 쉽게 해결 가능
• 모듈의 독립성을 높이기 위해서는 결합도는 약하게, 응집도는 강하게 해야함

결합도

• 모듈 간에 상호 의존도 또는 모듈 사이의 연관 관계
• 결합도와 품질은 반비례 관계
• 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움

*

응집도

• 정보 은닉 개념을 확장한 것으로 모듈의 내부 요소들의 서로 관련되어 있는 정도
• 모듈이 독립적인 기능으로 정의되어 있는 정도
• 응집도와 품질은 비례 관계

*

팬 인/아웃

• 팬 인 : 호출하는 모듈의 수
• 팬 아웃 : 호출되는 모듈의 수

*

공통 모듈

공통 모듈의 개요

• 여러 프로그램에서 공통적으로 사용할 수 있는 모듈
• 자주 사용되는 계산식이나 매번 필요한 사용자 인증 같은 기능들이 공통 모듈로 구성될 수 있음
• 공통 모듈의 명세 기법 : 정확성, 명확성, 완전성, 일관성, 추적성

재사용

• 비용과 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 개발에 사용하기 적합하도록 최적화 시키는 작업
• 재사용되는 대상은 외부 모듈과의 결합도는 낮고 응집도는 높아야 함

효과적인 모듈 설계 방안

• 결합도는 줄이고 응집도는 높여 모듈의 독립성과 재사용성을 높임
• 하나의 입구와 하나의 출구를 가져야 함

코드

코드의 개요

• 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위해 사용하는 기호
• 코드의 기능 : 식별 기능, 분류 기능, 배열 기능

코드의 종류

• 순차 코드 : 일정 기준에 따라 최초의 자료부터 일련번호를 부여하는 방법
• 블록 코드 : 대상 항목에서 공통적인 것을을 블록으로 구분하고 블록 내에 일련번호를 부여하는 방법
• 10진 코드 : 대상 항목을 0~9까지 10진 분할하고 다시 각각에 대하여 10진 분할을 필요한 만큼 반복하는 방법
• 그룹 분류 코드 : 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고 그룹 안에서 일련번호를 부여하는 방법
• 연상 코드 : 항목의 명칭이나 약호와 관계있는 숫자, 문자, 기호를 이용하여 코드를 부여하는 방법
• 표의 숫자 코드 : 항목의 성질(길이, 넓이, 부피 등)의 물리적인 수치를 그대로 코드에 적용시키는 방법
• 합성 코드 : 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 적용시키는 방법

코드 부여 체계

• 코드(이름)만으로도 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
• 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함

디자인 패턴

디자인 패턴의 개요

• 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
• 개발 과정에 문제가 발생 시 새로 해결책을 구상하기보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더욱 효율적임
• 재사용할 수 있는 기본형 코드들이 포함되어 있음

생성 패턴

• 객체의 생성과 참조 과정을 샘플화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램의 유연성을 더해줌
• 추상 팩토리 : 구체적인 클래스에 의존하지 않고 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
• 빌더 : 작게 분리된 인스턴스를 건축 하듯이 조합하여 객체 생성
• 팩토리 메소드 : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
• 프로토타입 : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
• 싱글톤 : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 수는 없음

구조 패턴

• 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
• 어댑터 : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
• 브리지 : 구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴
• 컴포지트 : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
• 데코레이터 : 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
• 퍼싸드 : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구상함으로써 서브 클래스의 기능을 간편하게 사용할 수 있도록 하는 패턴
• 플라이웨이트 : 인스턴스가 필요할 때마다 생성하는 것이 아닌 공유해서 사용함으로써 메모리를 절약하는 패턴
• 프록시 : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

행위 패턴

• 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의한 패턴
• 책임 연쇄 : 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
• 커맨드 : 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
• 인터프리터 : 언어에 문법 표현을 정의하는 패턴
• 반복자 : 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
• 중재자 : 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하는 패턴
• 메멘토 : 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
• 옵서버 : 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
• 상태 : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
• 전략 : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
• 템플릿 메소드 : 상위 클래스에서 골격을 정의하고 하위 클래스에서 처리를 구체화하는 구조의 패턴
• 방문자 : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴

4. 인터페이스 설계

시스템 인터페이스 요구사항 분석

시스템 인터페이스 요구사항 구성

• 시스템 인터페이스

  • 독립적으로 떨어져 있는 시스템들끼리 서로 연동하여 상호작용하기 위한 접속 방법이나 규칙

• 시스템 인터페이스 요구사항

  • 개발을 목표로 하는 시스템과 외부 시스템을 연동하는데 필요한 필요한 시스템 인터페이스에 대한 요구사항을 기술한 것

인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려사항 등

시스템 인터페이스 요구사항 분석

• 요구사항 명세서에서 요구사항을 기능적 요구사항과 비기능적 요구사항으로 분류하고 조직화하여 요구사항 명세를 구체화하고 이를 이해관계자에게 전달하는 일련의 과정
• 기능적 요구사항 : 시스템이 무엇을 하고 어떤 기능을 하는 가
• 비기능적 요구사항 : 시스템이나 프로젝트 개발 과정 등에서 지켜야 할 제약 사항

시스템 인터페이스 요구사항 분석 절차

요구사항 선별 -* 요구사항 관련 자료 준비 -* 요구사항 분류 -* 요구사항 분석 및 명세서 구체화 -* 요구사항 명세서 공유

인터페이스 요구사항 검증

인터페이스의 설계 및 구현 전 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지 검토하고 개발 범위의 기준인 베이스라인을 설정하는 것

인터페이스 요구사항 검토 계획 수립

*

인터페이스 요구사항 검토 및 오류 수정

• 체크리스트의 항목에 따라 인터페이스 요구사항 명세서 검토
• 요구사항 검토 시 오류가 발견되면 이를 수정할 수 있도록 오류 목록과 시정 조치서 작성
• 시정 조치서를 작성할 경우 조치가 완료되었는지를 확인하여 조치가 완료되면 인터페이스 요구사항 검토 작업을 완료

인터페이스 요구사항 베이스라인 설정

• 검증된 인터페이스 요구사항은 주요 의사 결정자에게 공식적으로 승인을 받음
• 소프트웨어 설계 및 구현을 위해 요구사항 명세서의 베이스라인 설정

요구사항 검증 방법

• 요구사항 검토 : 요구사항 명세서의 결함 여부를 검토 담당자들이 수작업으로 분석하는 방법

  • 동료검토 : 명세서 작성자가 직접 설명하는걸 동료들이 들으면서 결함을 발견하는 방법
  • 워크스루 : 검토 회의 전 미리 명세서를 배포하여 사전 검토 후 짧은 회의를 통해 결함을 발견하는 방법
  • 인스펙션 : 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하면서 결함을 발견하는 방법
• 프로토타이핑 : 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어서 최종 결과물을 예측
• 테스트 설계 : 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지 검토
• CASE(Computer Aided Software Enginerring) 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적, 분석, 관리하고 표준 준수 여부를 확인

인터페이스 요구사항 검증의 주요 항목

• 완전성 : 누락되지 않고 반영되었는가
• 일관성 : 모순되거나 충돌되는 점 없이 일관성을 유지하는가
• 명확성 : 모든 참여자가 명확하게 이해할 수 있는가
• 기능성 : 어떻게보다 무엇을에 중점을 두고 있는가
• 검증 가능성 : 사용자의 요구를 모두 만족하고 개발된 소프트웨어가 요구 내용과 일치하는지를 검증할 수 있는가
• 추적 가능성 : 명세서와 설계서를 추적할 수 있는가
• 변경 용이성 : 명세서의 변경이 쉽도록 작성되었는가

인터페이스 시스템 식별

개발 시스템 식별

• 인터페이스 관련 자료들을 기반으로 개발하고자 하는 시스템의 상세 식별 정보를 정의하고 목록을 작성
• 시스템 아키텍쳐 : 시스템 내부에서 하위 시스템이 어떻게 상호작용하는지 파악할 수 있도록 구성이나 동작원리를 나타냄
• 유스케이스 : 사용자의 요구사항을 기능 단위로 표현

내/외부 시스템 식별

• 인터페이스 관련 자로들을 기반으로 개발할 시스템과 연계할 시스템들의 상세 식별 정보를 정의하고 목록을 작성

내˙외부 시스템 환경 및 관리 주체 식별

• 연계할 시스템 접속에 필요한 IP, URL, Port 정보 등 시스템의 실제 운용 환경 및 하드웨어를 실제적으로 관리하는 담당자를 확인

내˙외부 시스템 네트워크 연결 정보 식별

• 내˙외부 시스템을 연계하는데 필요한 네트워크 연결 정보 확인

인터페이스 식별

• 인터페이스 요구사항 명세서와 인터페이스 요구사항 목록을 기반으로 개발할 시스템과 연계할 시스템 사이의 인터페이스를 식별하고 목록을 작성

인터페이스 시스템 식별

• 인터페이스별로 인터페이스에 참여하는 시스템들을 송신 시스템과 수신 시스템으로 구분하여 작성

송수신 데이터 식별

식별 대상 데이터 : 송수신 사이에 교환되는 데이터. 규격화된 표준 형식에 따라 전송

• 인터페이스 표준 항목 : 송수신 시스템을 연계하는데 표준적으로 필요한 데이터

  • 시스템 공통부 : 시스템 연동 시 필요한 공통 정보
  • 거래 공통부 : 시스템이 연동된 후 송수신되는 데이터를 처리할 때 필요한 정보
• 송수신 데이터 항목 : 송수신 시스템이 업무를 수행하는 데 사용하는 데이터
• 공통 코드 : 시스템들에서 공통적으로 사용하는 코드

정보 흐름 식별

• 개발할 시스템과 내외부 시스템 사이에서 전송되는 정보들의 방향성 식별

송수신 데이터 식별

• 개발할 시스템과 연계할 시스템 사이의 정보 흐름과 데이터베이스 산출물을 기반으로 식별
• 인터페이스 표준 항목과 송수신 데이터 항목 식별
• 코드성 데이터 항목 식별

인터페이스 방법 명세화

• 내외부 시스템이 연계하여 작동할 때 인터페이스별 송수신 방법, 손수신 데이터, 오류 식별 및 처리 방안에 대한 내용을 문서화한 것

시스템 연계 기술

• 개발할 시스템과 내외부 시스템을 연계될 때 사용하는 기술
• DB Link : DB에서 제공하는 DB Link 객체 이용
• API/Open API : 송신 시스템의 DB에서 데이터를 읽어 와 제공하는 Application Programming Interface 프로그램

• 연계 솔루션 : EAI 서버와 송수신 시스템에 설치되는 클라이언트 이용

  • EAI : 송수신 데이터를 식별하기 위해 송수신 처리 및 진행 현황을 모니터링하고 통제하는 시스템
• Socket : 서버에서 소켓을 생성하여 클라이언트의 통신 요청 시 클라이언트와 연결하여 통신하는 네트워크 기술
• Web Service : 웹 서비스에서 WSDL, UDDI, SOAP 프로토콜을 이용하여 연계하는 서비스

인터페이스 통신 유형(단방향, 동기, 비동기)

• 데이터를 송수신 하는 형태
• 단방향 : 시스템에서 거래 요청 후 응답 없음
• 동기 : 시스템에서 거래 요청 후 응답이 올 때까지 대기
• 비동기 : 시스템에서 거래를 요청 후 응답이 올때까지 다른 작업을 하면서 대기

인터페이스 처리 유형(실시간, 지연, 배치)

• 송수신 데이터를 어떤 형태로 처리할 것인지에 대한 방식
• 실시간 방식, 지연 처리 방식, 배치 방식(대량 데이터 처리)

인터페이스 발생 주기

• 송수신 데이터가 전송되어 인터페이스가 사용되는 주기

송수신 방법 명세화(연계 방식, 통신 유형, 처리 유형, 발생 주기)

• 연계 방식, 통신 유형, 처리 유형, 발생 주기

송수신 데이터 명세화

오류 식별 및 처리 방안 명세화

시스템 인터페이스 설계서 작성

• 시스템의 인터페이스 현황을 확인하기 위해 시스템이 갖는 인터페이스 목록과 상세 데이터 명세를 정의한 문서

시스템 인터페이스 목록 작성

• 업무 시스템과 내외부 시스템 간 데이터를 주고받는 경우에 사용하는 인터페이스에 대해 기술

시스템 인터페이스 정의서 작성

• 인터페이스별로 시스템 간의 연계를 위해 필요한 데이터 항목 및 구현 요건 등을 기술

미들웨어 솔루션 명세

미들웨어의 개념 및 종류

• 운영체제와 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
• 표준화된 인터페이스를 제공하여 시스템 간의 데이터 교환에 일관성을 보장

*

미들웨어 솔루션 식별

• 개발 및 운용 환경에 사용될 미들웨어 솔루션을 확인하고 목록을 작성

미들웨어 솔루션 명세서 작성

• 미들웨어 솔루션 목록의 미들웨어 솔루션별로 관련 정보들을 상세하게 기술
• 제조사의 제품 소개서 검토
• 제공 기능 및 특징 검토
• 제약사항 검토